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Abstract 


The Next Generation Air Transportation System (NextGen) concept for 2025 envisions the movement 
of large numbers of people and goods in a safe, efficient, and reliable manner. The NextGen will remove 
many of the constraints in the current air transportation system, support a wider range of operations, and 
deliver an overall system capacity up to 3 times that of current operating levels. In order to achieve the 
NextGen vision, research is necessary in the areas of surface traffic optimization, maximum runway 
capacity, reduced runway occupancy time, simultaneous single runway operations, and terminal area 
conflict prevention, among others. 

The National Aeronautics and Space Administration (NASA) is conducting Collision Avoidance for 
Airport Traffic (CAAT) research to develop technologies, data, and guidelines to enable Conflict 
Detection and Resolution (CD&R) in the Airport Terminal Maneuvering Area (ATMA) under current and 
emerging NextGen operating concepts. In the following, an initial concept for an aircraft-based method 
for CD&R in the ATMA is presented. This method is based upon previous NASA work in CD&R for 
runway incursion prevention, the Runway Incursion Prevention System (RIPS). CAAT research is 
conducted jointly under NASA ’s Airspace Systems Program, Airportal Project and the Aviation Safety 
Program, Integrated Intelligent Flight Deck Project. 

1 Introduction 

By 2025, U.S. air traffic is predicted to increase 3-fold, yet the current air traffic management system 
may not be able to accommodate this growth. In response to this challenge, a consortium of industry, 
academia, and government agencies have proposed a revolutionary new concept for U.S. aviation 
operations, termed the Next Generation Air Transportation System or “NextGen” [JPDO 2004]. 
Emerging NextGen operational concepts represent a different approach to air traffic management and as a 
result, a dramatic shift in the tasks, roles, and responsibilities for the flight deck to ensure a safe, 
sustainable air transportation system. 

To support the operational goals - the “vision” - of NextGen, the Joint Planning and Development 
Office (JPDO) has published a Concept of Operations (ConOps) [JPDO June 2007] and a research and 
development plan [JPDO August 2007] to develop the technologies that it considers vital to reach the 
NextGen goals. While this vision is not necessarily shared by all nor is it the only way to achieve 
NextGen, it does illustrate many of the challenges to achieving a NextGen operating environment. In 
particular, key challenges associated with the NextGen ATMA include: 

• Trajectory-based operations that use closely spaced arrivals and departures to enable airport safety 
and capacity, independent of the visibility and weather conditions. 

• Arrival and departure procedures that shift away from rigid, clearance-based air traffic control 
processes to flexible, adaptive air traffic management principles utilizing reduced spacing buffers, 
more runways, and innovative merging and spacing 4-dimensional (4-D) trajectory operations. 

• Automated surface management systems that utilize dynamic algorithms to calculate the most 
efficient movement of all surface traffic to increase efficiency [Cheng, et. al., 2003]. Pilots will be 
required to comply with 4-D taxi clearances, dictating that aircraft arrive at specific locations 
within specific time windows. 

• Potential pilot responsibility for “separation” from other aircraft, during all phases of flight, 
regardless of visibility conditions. 

Proactive safety layers are being designed to enable these emerging NextGen operational concepts. 
Automation to manage, assist, and even conduct these procedures and operations will be developed. 
Nonetheless, it is imperative to have a conflict detection system that is an integral part of and integrated 
with, the emerging NextGen technologies to provide an additional protective layer should these proactive 
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measures unforeseeably fail. This critical need is recognized under the JPDO vision in its research and 
development plan [JPDO August 2007]. 

This paper presents an initial concept for an aircraft-based method for CD&R in the ATMA. A 
concept and technical description is given for CD&R algorithms that detect potential conflicts in the 
ATMA during runway, taxiway, and low altitude operations and generate alerts and possibly resolution 
advisories for display to the pilot. Note that in this paper, conflict is defined as a condition that can lead 
to a collision if no avoidance action is taken. 


2 Background 

Relevant research and systems for CD&R in the ATMA are discussed. 

2.1 Runway Incursions 

The harmonized Federal Aviation Administration (FAA)/Intemational Civil Aviation Organization 
(ICAO) definition for runway incursion [FAA September 2007], adopted on October 1, 2007, is: 

Any occurrence at an aerodrome involving the incorrect presence of an aircraft, vehicle, or person on 
the protected area of a surface designated for the landing and take-off of aircraft. 

Runway incursions are a serious aviation safety hazard. The National Transportation Safety Board 
continues to have improving runway safety on its most wanted list of transportation safety improvements 
for aviation [NTSB 2007]. In the four year period between 2003 and 2006, 1,306 runway incursion 
events were reported, which is a rate of almost 1 runway incursion event per day [FAA September 2007]. 
The worst aviation accident - 583 fatalities - was caused by a runway incursion in 1977 when two fully 
loaded 747 airplanes collided on a runway at Tenerife airport. The accident occurred in low visibility 
(300 meters visual range) conditions. A departing aircraft crashed head-on into an aircraft taxiing in the 
opposite direction on the same runway. The present-day statistics and events are cause enough for alarm 
but, without proactive counter-measures, the increase in air traffic forecasted under NextGen could 
potentially result in catastrophic increases in runway incursion accidents. 

Numerous efforts have been launched by the FAA, industry, and others to reduce the frequency of 
runway incursions and the risk of runway collisions to meet the recommendations put forth by the NTSB 
[NTSB 2000]. Current FAA initiatives include a combination of technology, infrastructure, procedural, 
and training interventions [FAA September 2007]. These solutions include Airport Surface Detection 
Equipment Model X (ASDE-X), Airport Movement Area Safety System (AMASS); Final Approach 
Runway Occupancy Signal (FAROS); Runway Status Lights (RWSL); enhanced controller training; 
airport surface operations advisory circulars; improved airport markings and lighting; improved pilot 
education, training, and awareness; and revised pilot/controller communications phraseology. These 
efforts target improved awareness and enhanced surveillance, but do not include technology solutions for 
the flight deck. 

Currently, there is not a system available (either ground or aircraft-based) that directly provides pilots 
with alerts of potential runway conflicts with other traffic. However, some flight deck incursion 
awareness systems are available, including: 

• Honeywell International Inc. has developed an aircraft-based Runway Awareness and Advisory 
System (RAAS) [Honeywell 2006]. RAAS uses GPS position data and a database to provide 
aural-only advisories that supplement flight crew awareness of own aircraft position during 
ground operations and on approach to landing. RAAS does not, however, provide alerts of runway 
incursion conflicts with other traffic. 

• SafeRoute™, developed by Aviation Communication & Surveillance Systems (ACSS), provides 
the pilot with an electronic map of the airport surface on an electronic flight bag, showing ownship 
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and other aircraft positions. The system will also indicate when a runway is occupied by 
highlighting the runway on the display [Evans 2007]. SafeRoute™ does not, however, detect and 
alert for conflicts between aircraft and vehicles. 


NASA and FAA-sponsored research has also been conducted by Honeywell Aerospace and Sensis 
Corp. to transmit ASDE-X runway incursion alerts, which are optimized for Air Traffic Control (ATC), to 
the flight deck [Hughes 2007]. Additional research is needed to determine the effectiveness of providing 
the ATC optimized ASDE-X alerts to the flight crew and data link requirements. 

Working cooperatively with NASA, Era Corporation has developed a conflict detection and alerting 
system, known as PathProx™, that detects potential runway conflicts and generates alerts for display to 
the flight crew [Cassell, et. al, 2003]. PathProx™ does not include the cockpit display device and is not 
commercially available at this time. 

Under NASA’s Aviation Safety Program, Synthetic Vision Systems Project, the Runway Incursion 
Prevention System (RIPS) was developed to address the growing problem of runway incursions as a 
significant contributor to the fatal aviation accident rate in commercial, business, and general aviation 
sectors [Jones, et. al., 2001, Jones 2002, Jones 2005, and Jones and Prinzel 2006]. As part of this work, 
the Runway Safety Monitor (RSM) was conceived as a method of automated CD&R for approach, 
landing, and surface (runway) operations. This effort focused on flight deck technologies and alerting, in 
contrast to other agency and company initiatives. 

2,2 Low Altitude Air-to-Air Conflicts 

In today’s operations, the principal airborne method of CD&R for separation assurance is provided by 
the Traffic Alert and Collision Avoidance System (TCAS). TCAS predicts a penetration to an aircraft’s 
airspace and provides associated alerts to the flight crew. TCAS has been developed and improved for 
over 15 years and has been very effective in reducing or eliminating airborne collisions. This system has 
limitations in the vicinity of airports and TCAS alerts are inhibited at low altitudes. Resolution 
Advisories (RAs) are not issued below 1000 feet Above Ground Level (AGL) and audible Traffic 
Advisories (TAs) are not issued below 500 feet AGL [FAA 2000]. Research to date indicates that the use 
of TCAS may work for envisioned trajectory-based 4-D operations [Ivanescu, et. al., 2004], but the 
suitability of TCAS degrades in operations nearing the airport [Pritchett, et. al., 1995]. 

A new RTCA committee (SC-218, Future ADS-B/TCAS Relationships) is being established to assess 
the relationship between ADS-B and TCAS from 2020 to 2025 and is expected to further develop 
concepts for interoperation between ADS-B and TCAS [RTCA 2008]. 

2.3 Taxi Conflicts 

The NextGen concept proposes the use of ground-based automation to schedule surface traffic and 
generate 4-D taxi clearances to enable precise departure times and limited simultaneous runway 
occupancy [JPDO June 2007]. This move toward 4-D surface operations pushes the CD&R need beyond 
the runway and must include all surface operations. Research has been initiated to determine the 
information display requirements for presentation of automated 4-D taxi clearances to the pilot and the 
ability of the pilot to comply with the 4-D clearances [Williams, et. al., 2006]. Research is yet to be 
conducted to determine the safety impacts of following 4-D taxi clearances. It is anticipated that the pilot 
may be so focused on following 4-D clearances to meet scheduled arrival times that unintentional taxi 
conflicts result. If this is the case, taxi conflict detection capability becomes critical. 

2.4 ATCAM Concept 

For emerging NextGen operating concepts, CD&R capabilities are desirable as the last of several 
proactive safety-enabling layers. To provide a basis for this development and to begin research under 
CAAT, an initial concept for CD&R in the ATMA is proposed in the following as an extension of the 
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RIPS work. This concept - Airport Traffic Collision Avoidance Monitor (ATCAM) - is described in the 
following sections. Also, the data communications to support this application are described to assess the 
feasibility of the concept, given current and projected equipage and current and NextGen operating 
environments. 


3 ATCAM Concept Description 

The goal of ATCAM is to detect potential traffic conflicts in the ATMA and generate alerts and 
possibly resolution advisories that can be displayed to the pilot to provide sufficient awareness so that 
collisions are avoided. ATCAM operates at low altitudes near the airport without conflicting with TCAS, 
as well as on the runway and during taxi and ramp operations for multiple classes of aircraft and surface 
vehicles. 

ATCAM is comprised of three separate aircraft-based algorithms that rely on target state information 
that can be obtained from various sources: 

1. The Runway Safety Monitor (RSM) is designed to detect runway incursion conflicts and generate 
alerts that provide the flight crew with sufficient awareness to take action to avoid a collision. RSM was 
developed in support of RIPS research and is retained as a core element of ATMA CD&R. 
Enhancements are planned for RSM based on current and emerging NextGen operational concepts and 
research findings. 

2. The Low Altitude Conflict Monitor (LACM) is designed to detect and alert for air-to-air conflicts 
at low altitudes near the airport. 

3. The Taxi Conflict Monitor (TCM) is designed to detect and alert for ground taxi conflicts 
anywhere in the airport movement and ramp areas. 

The three algorithms are separate and independent but are integrated and share data to increase the 
probability of detection for all possible conflicts during airport operations. RSM has been through 
extensive testing, however, LACM and TCM are in the initial development stage and have not been fully 
tested. The ATCAM algorithms are being developed for NASA by Lockheed Martin. 

Figure 1 is a high level flow chart depicting the process for ATCAM conflict detection including 
coordination and prioritization of alerts in the event of multiple alerts from the same or multiple 
algorithms. A description of this process follows. 

When the ownship is on the surface or at low altitude and new traffic data becomes available (see 
Section 4.0, ATCAM Data Communications Requirements), the RSM algorithm runs first to monitor 
other airborne or ground traffic for possible runway incursions. After RSM completes, either the LACM 
algorithm or the TCM algorithm is called depending on the position of the ownship. If the ownship is on 
the ground, TCM monitors possible conflicts with other aircraft or vehicles anywhere on the airport 
surface. If the ownship is airborne, LACM monitors possible conflicts with other airborne aircraft. 

It is possible for conflicts detected by TCM or LACM to overlap with RSM (i.e., a TCM/LACM 
conflict could also be a runway incursion) and conflicts can also occur that are not runway incursions. 
ATCAM resolves any differences between alerts issued by the algorithms and prioritizes the alert data for 
output. The alert data, or null data if no alerts, is then output for use by the flight deck aural and graphical 
displays (see Section 4.3, Output Data Requirements). 

This process of reading the ownship and traffic data, calling the conflict detection algorithms, 
coordinating and prioritizing alerts, then outputting the alert data is repeated approximately once per 
second. All algorithms are enabled by default but can be individually disabled. Each algorithm is 
implemented using the concept and technical approach that is optimal for the type of conflict being 
monitored. 

A high level description of the alerting concept and algorithms is given in the following sections. The 
ATCAM concept will be updated as necessary to address new or different (based on test and evaluation) 
CAAT requirements and concepts for NextGen. 
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Figure 1. ATCAM High Level Flow Diagram 
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3.1 Alert Definitions 


A govemment/industry subcommittee (RTCA Special Committee (SC) 186, Working Group (WG) 1) 
is in the process of developing an application description for aircraft-based surface alerting, focusing on 
runway safety. This subcommittee has adopted the definition of alerts as specified in [FAA 2007], as 
follows: 

Alerts refer to flight deck annunciations, meant to attract the attention of, and identify to the flight 
crew a non-normal operational or airplane system condition. Cautions and warnings are examples of 
alerts. Cautions alert for conditions that require immediate flight crew awareness and subsequent flight 
crew response. An auditory signal and the yellow/amber color are associated with Cautions. Warnings 
alert for conditions that require immediate flight crew awareness and immediate flight crew response. An 
auditory signal and the red color are associated with Warnings. 

All ATCAM algorithms use a common concept and naming convention for alerts that is based on the 
convention used by TCAS and RTCA SC-186 WG1 definitions. The criteria and thresholds used for the 
ATCAM alerts are defined in Sections 5.4, 5.5, and 5.6. 

The alert terminology used by ATCAM is as follows: 

3.1.1 Traffic Advisories (TA) 

A TA is a cautionary alert that provides immediate awareness of other traffic that may cause an 
unsafe or a hazardous situation. In the initial design, TAs are issued by LACM and TCM for low altitude 
and taxi operations and by RSM for runway incursions during approach or when holding in position on 
the runway. The feasibility and appropriateness of generating TAs for these types of operations will be 
determined based on test and evaluation. Evasive maneuvers are not required and resolution instructions 
are not given when a TA is issued. In some cases, appropriate action may be advisable at the pilot’s 
discretion to prevent the condition from progressing to a more serious situation. For example, when a TA 
is issued for taxi operations, evasive action such as slowing down or stopping may be done to prevent the 
situation from progressing to the point a conflict advisory is warranted. 

3. 1.2 Conflict Advisories (CA) 

A CA is a warning that there is a high probability of collision or near collision with other traffic and, 
therefore, evasive action should be initiated. The specific maneuver taken (e.g., go-around, abort takeoff, 
stop taxi, etc.) is at the pilot’s discretion. CAs are issued by RSM, LACM and TCM using criteria and 
thresholds that are algorithm specific. The criteria and thresholds will be refined based on test and 
evaluation. 

3.1.3 Resolution Advisories (RA) 

RAs are intended to provide the pilot direction on the maneuver to take to safely avoid a collision. 
RAs are not issued in the initial version of ATCAM. Further research is required, and currently in 
progress, to determine the feasibility of providing RAs in conjunction with CAs to effectively resolve 
conflict situations without producing undesired consequences. For example, what evasive maneuvers 
should be taken without creating secondary conflicts with other traffic? Section 6.0, Initial Requirements 
for ATCAM Resolution Advisories, describes current RA research. 


3.2 Runway Safety Monitor (RSM) 

RSM monitors data for the ownship aircraft and other aircraft, obstacles, or vehicles and predicts 
potential incursions/collisions and alerts the pilot in anticipation to avoid the incursion/collision. Testing 
has included single runway, intersecting runways and intersecting flight path scenarios during both 
simulation and flight [Green 2006, Jones 2002 and 2005, Jones, et. al., 2001, and Jones and Prinzel, 
2006]. In some scenarios, RSM detects a runway incursion early and issues an alert before the situation 
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degenerates into a severe incursion. In other scenarios, RSM predicts the incursion before it occurs and 
alerts the pilot early to avoid the incursion. RSM also detects runway conflicts that are not part of the 
strict definition of runway incursion, such as when both aircraft are airborne in the process of landing in 
the approach phase and/or taking off in the climb out phase. RSM is generic for both general aviation 
(GA) and large commercial air carrier operations, and for any ownship aircraft type. The most recent 
version of RSM is described in detail in [Green 2006]. 

A major concept of RSM is the use of runway incursion (RI) zones. A RI zone is a software-derived 
three-dimensional virtual zone that overlays a runway and the approach area (see Section 5.4.2). The 
width of the zone extends a constant distance from both sides of the runway, and the length of the zone 
extends a constant distance from both thresholds of the runway. The zone altitude extends vertically a 
constant altitude above the runway surface. Figure 2 shows a two-dimensional plan view of the RI zones 
at the Wallops Flight Facility (WAL). RSM monitors for conflicts/incursions only when the ownship is 
inside a RI zone and below the zone altitude, and traffic is inside the same zone as the ownship or in an 
intersecting zone. 

Another major RSM concept is the use of operational states for the ownship and traffic. Seven 
operational states or flight phases are defined: taxi, pre-takeoff, takeoff roll, climb-out, approach, rollout 
and fly-thru. These states are described in Appendix A. Combinations of these states between the 
ownship and traffic, positions inside the RI zones, and other criteria determine whether or not a conflict 
advisory will be issued. More detail is provided in Section 5.4 and Appendices A and B. 

CD&R under the RIPS concept includes aural and visual displays on the flight deck. For instance, an 
airport map display depicting a conflict advisory for a runway incursion from a simulation at the Chicago 
(ORD) airport is shown in Figure 3. 



Figure 2. Runway Incursion Zones at Wallops Flight Facility 
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Figure 3. Airport Map Display showing Runway Incursion 

3.3 Low Altitude Conflict Monitor (LACM) 

The intent of the LACM algorithm is to monitor conflicts that can occur at low altitudes near the 
airport including conflicts that may not be detected by RSM. As shown in Figure 1 above, LACM is run 
in addition to RSM. LACM provides conflict detection coverage at altitudes below 1000 feet. The 
implementation of LACM does not utilize aircraft operational state information and RI zones as does 
RSM. Instead, the algorithm’s initial design is based on many of the same concepts that are used in the 
current operational version of TCAS II [FAA 2000]. However, there are a number of significant 
differences between LACM and TCAS in the way traffic data is obtained, the methods of computation, 
the criteria and thresholds used for alerting, and the types of alerts that are issued (see Section 5.5). Some 
of the TCAS terminology is also used by LACM such as Closest Point of Approach (CPA), time to CPA 
(called range tau) and time to co-altitude (called vertical tau). The technical approach for LACM is to 
compute closing speed, range tau, vertical tau and other data between ownship and an approaching 
aircraft to determine if specific criteria and thresholds are met for issuing alerts. The alerts and 
methodologies used by LACM are designed to achieve the same high level of performance as TCAS and 
are described in Section 5.5. 

Figure 4 gives examples of LACM traffic and conflict advisories at the ORD airport. In Figure 4a, 
the ownship has departed a runway. The traffic has departed a parallel runway and is turning on a path to 
cross in front of ownship. LACM detects this potential conflict and initially issues a TA (indicated by 
yellow icons). As the scenario progresses, the aircraft continue toward a potential collision point and 
LACM issues a CA (indicated by red icons), as shown in Figure 4b. 
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4a. LACM Traffic Advisory 



4b. LACM Conflict Advisory 


Figure 4. LACM Alerts. 
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3.4 Taxi Conflict Monitor (TCM) 


The TCM algorithm is designed to improve safety on the airport surface by monitoring for conditions 
that cause conflicts and collisions during taxi and ramp operations for multiple classes of aircraft as well 
as surface vehicles (trucks, baggage carts, etc.). The algorithm’s initial design uses an approach similar to 
LACM by computing distances between aircraft, closing speeds, time to closest point of approach (range 
tau) and other parameters used for alert criteria. The obvious difference from LACM is that all aircraft, 
vehicles, etc., on the airport surface can be very close to each other while moving or not moving. 

The close proximity of aircraft and vehicles to one another on the surface requires very strict accuracy 
tolerances. These tolerances, as well as all alert criteria and thresholds for TCM, are described in Section 
5.6. Some of the parameters used by LACM (e.g., vertical speed, altitude, vertical tau, etc.) are not 
required by TCM. However, based on developmental testing, additional alert criteria are required by 
TCM because of the higher probability of false and nuisance alerts. All alert criteria and thresholds are 
described in Section 5.6. Because TCM is based on the LACM and the TCAS concept, the algorithm 
does not use a detailed database of airport taxiways, runways and ramps. 

The feasibility of utilizing traffic’s ATC clearances, specifically, assigned taxi route and hold short 
instructions, as a factor in taxi conflict detection and alerting is being investigated. Knowledge of the 
traffic’s intent on the surface combined with the current state information could result in delayed alerting 
and reduced nuisance alerts. A detailed database of the airport including taxiways and ramp areas would 
be required in this instance. Future versions of TCM may utilize this information if determined to be a 
feasible approach. 

Figure 5 gives examples of TCM traffic and conflict advisories. In Figure 5a, the taxiing traffic and 
ownship are approaching the same intersection as ownship exits the runway after landing. TCM detects 
this potential conflict, and initially issues a TA (indicated by yellow icons). In Figure 5b, as the aircraft 
continue to converge, TCM issues a CA (indicated by red icons). 



5 a. TCM Traffic Advisory 
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5b. TCM Conflict Advisory 
Figure 5. TCM Alerts between commercial aircraft. 


4 ATCAM Data Communications 

The ICAO defined operational requirements for Advanced Surface Movement Guidance and Control 
Systems (A-SMGCS) are to achieve safe, orderly and expeditious movement of aircraft and vehicles at 
airports under all visibility conditions, traffic densities, and airport layouts. These standards were 
proposed by ICAO to ensure safety and standardization with respect to global interoperability [ICAO 

1997] . NASA and its industry partners developed a prototype A-SMGCS architecture and operational 
concept that was initially designed to improve operational capability. This operational concept and 
system design have been tested in both full-mission simulation and operational flight test experiments at 
major airport facilities. The data structure developed for the first implementation of an aircraft-based A- 
SMGCS, demonstrated at the Atlanta Hartsfield International Airport (ATL) in 1997 [Jones and Young, 

1998] , coupled with the enhanced design to provide runway incursion detection and alerting demonstrated 
at Dallas-Fort Worth International Airport (DFW) in 2000 [Jones, et. al., 2001] were used as the basis for 
the current data parameters for ATCAM. 

ATCAM data communications is handled by a separate software program that accesses data from 
various sources available on the aircraft and provides the data to ATCAM. Flight and traffic data are 
obtained from available sources and converted and processed into the format required by ATCAM. This 
method of data communications has been utilized successfully in past RIPS research and has proven to be 
highly reliable and effective during flight tests and simulations. A significant advantage of this method is 
that ATCAM does not have to perform data communications functions. Appendix C lists the current data 
parameters used by ATCAM. 

ATCAM does not utilize data on current weather conditions or other phenomena such as wake 
vortices in the conflict detection calculations. 

Appendix D contains a discussion on surveillance performance and intent data as it relates to ATMA 
CD&R. 
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4.1 Ownship Data 


The ownship data used by the ATCAM software is obtained from the aircraft systems and consists of 
the data described in Appendix C, as available. Additional parameters may be required with future 
development of the ATCAM software. 


4.2 Traffic Data 

Data for airport traffic can be obtained from several different sources, such as: 

• Traffic Information Service-Broadcast ( TIS-B) comprised of traffic information from surface 
surveillance radar and multilateration [RTCA 2007], 

• Automatic Dependent Surveillance-Broadcast (ADS-B) [RTCA 2002], 

• TCAS [FAA 2000], and 

• GPS-based surface vehicle location tracking system such as Era Corporation’s Squid [Era 2008]. 

Appendix C contains a list of the traffic data parameters currently used by ATCAM. 

For CAAT, the data communications software accesses traffic data from any available source. If any 
of the parameters are not available from the data source in use, they are marked accordingly, so that 
ATCAM does not attempt to use any spurious values. Unavailable parameters may be computed 
independently, or may be subject to data smoothing, described below. ADS-B is being improved and is 
expected to be the primary source for future NextGen requirements. However, current Mode-S/Mode-C 
TCAS data (range, bearing and relative altitude) will continue to be used as well as other new sources 
from on-board sensors and ground systems. Since ATCAM does not utilize range, bearing and relative 
altitude, TCAS data must be converted to lat/long and altitude MSL by the communications program for 
use by ATCAM. Currently, ATCAM accesses data once per second, regardless of the rate at which the 
data was received. 

When traffic parameters are not reported or not up to date, an estimate of the current value(s) must be 
computed by the algorithms based on the last known value(s). This process, known as data smoothing, 
involves computations that decrease in accuracy with increasing time between updates. Computation 
accuracy is further decreased if data rates for specific values are different and the exact times since the 
last update are uncertain (for example, the position update is one hertz but the ground speed is updated at 
two or three hertz and the exact update times are unknown). 

4.3 Output Data 

ATCAM output parameters provide information on the generated alert and conflict traffic to enable 
display of the alert to the flight crew or ATC. The specific output parameters for the alert are based on 
the aural and graphical flight deck alerting display requirements. The current ATCAM output parameters, 
listed below, were defined for RSM alerts. Additional parameters are available in RSM and can be 
provided in future upgrades as required. Other output parameters derived from LACM and TCM alerting 
display requirements will also be added as required. 

• Traffic id (e.g., ICAO aircraft address) 

• Alert code 

• Distance to traffic or collision point (range) 

• Time (sec) to collision point or closest point of approach (range tau) 

The alert code is a single four digit hex number that compresses information for the alert including 
type of alert (i.e., caution or warning), the name of the traffic’s runway and the traffic’s departure/arrival 
status (for example, a warning for traffic departing runway 25). The efficient encoding and decoding 
routines used to generate the alert code are generic for any aiiport and compatible with the ATC two-way 
Controller-Pilot Data Link Communications (CPDLC) protocols defined in references [ICAO 1999] and 
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[RTCA1993], A benefit of being compatible with CPDLC is the alert information can be data linked to 
ATC for display on a controller’s workstation as well as be presented aurally, visually or both to the pilot. 


5 Technical Description of ATC AM Algorithms 

The previous section described data communications and parameters for the ATCAM algorithms. 
This section provides a technical description for each of the three algorithms. The first three subsections 
on integration of algorithms, performance, and aircraft reference positions are applicable to all three 
algorithms. Finally, algorithm-specific details are presented. 

5.1 Integration of Algorithms 

Because there is overlap in the coverage of component algorithms in ATCAM, the algorithms are 
integrated to share data and insure that consistent and accurate alerts are issued. The LACM algorithm is 
integrated with the RSM algorithm to detect any air-to-air conflicts that RSM does not alert for when the 
conflict does not meet incursion criteria. The TCM algorithm is also integrated with RSM because 
ground taxi conflicts can also be runway incursions if the conflict occurs on or near a runway. Integration 
between LACM and TCM is not necessary since there is no overlap between the algorithms’ operational 
domains. 

The integration of LACM and TCM with RSM is implemented by sharing and coordinating alert 
output data. Since LACM and TCM run after RSM (see Figure 1) and have access to RSM data, 
information is known about ownship and traffic operational states and RSM alert status. This information 
is used to coordinate the alert data that is output for aural and graphical display in the cockpit. For 
example, when air-to-air conflicts are also runway incursions, the ownship and traffic runway status 
information from RSM can be issued in addition to the low altitude alert data. Due to design differences, 
there are cases when alert criteria will be met by only one algorithm or one algorithm may detect a 
conflict earlier than the other. This redundancy in conflict monitoring significantly improves overall 
performance. 


5.2 Algorithm Performance 

The algorithms will be evaluated based on timeliness of alerts, missed alerts, false alerts, and 
nuisance alerts for TAs and CAs. The timeliness of an alert is determined by whether a TA is issued with 
sufficient time to provide adequate traffic situation awareness prior to a potential hazardous situation, or 
whether a CA is issued with sufficient time for the pilot to take action and safely avoid a collision. A 
missed alert occurs when conditions meet the criteria for a CA or TA but the alert is not issued. For 
example, a runway incursion or near collision occurs and a CA was not issued, or aircraft come close 
enough to meet the TA minimum separation threshold but the TA is not issued. A false alert is an 
incorrect or spurious alert caused by a failure of the alerting system including the sensor [FAA 2007]. An 
example of a false alert is an alert issued on traffic that is not real (i.e., erroneous traffic data). A nuisance 
alert is generated by a system that is functioning as designed but which is inappropriate or unnecessary 
for the particular condition [FAA 2007]. A false or nuisance alert could cause an evasive maneuver that 
is not necessary and could possibly cause secondary conflicts or unnecessary delays. 

The algorithms are being designed to completely eliminate collisions/near collisions in the airport 
area. To accomplish this goal, performance results should be near zero missed and untimely alerts. 
Analyses are required to determine acceptable missed and false alert rates and desired probability of 
detection. These analyses will be a product of the RTCA SC- 186 WG1 subcommittee. 

Performance objectives for RSM have been met in previous flight tests and piloted simulations. The 
most recent RSM flight test results at Wallops Flight Facility verified a success rate of no missed or late 
alerts and only one false alert for all incursion scenarios tested [Green 2006]. 
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5.3 Aircraft Reference Positions 


ATCAM uses the latitude and longitude reported for ownship and traffic as the navigation reference 
point for the aircraft (or vehicles). This reference point is the aircraft center of gravity. To determine 
distance between aircraft, ATCAM measures the distance between the exteriors of the aircraft, not the 
distance between reference points. To determine whether an aircraft is in a runway incursion zone, 
ATCAM considers whether any exterior point of the aircraft is in the zone, not just the reference point. 
ATCAM determines the aircraft exterior points by considering the aircraft type (B-757, DC-7, etc.) and 
using the dimensions for that aircraft type (body length, wing span, distance to nose, and distance to tail). 
If the aircraft type is unknown, ATCAM uses a default type of a large aircraft (B-747) to allow a 
conservative estimate. 


5.4 RSM 


5.4.1 A irport Databases 

RSM does not require detailed terrain or aiiport databases that include taxiways, ramps, buildings, 
etc. However, RSM does require highly accurate information for all runways on the airport to include 
latitude and longitude of thresholds and displaced thresholds, runway length and width, length of run-up 
areas, runway true heading, 1LS glide slope angle if applicable, runway touchdown aim points, and 
distance from threshold to land-and-hold-short positions on the runway. The existence of intersecting 
runways and intersecting arrival/departure flight paths is determined from the airport diagram. All airport 
information is easily available from internet sources. 

5.4.2 Runway Incursion Zone Placement 

Accurate placement of RI zones is critical for correct performance of the algorithm and prevention of 
false, missed, and nuisance alerts. The coordinates for the sides and ends of each zone are computed 
based on runway information in the airport configuration file and vary for each runway. The sides of the 
zones are set to be at or just inside the hold short positions if the exact positions are known. If hold short 
position data are not available, the sides of zones are placed 200 feet from the runway edges. 

The ends of zones will vary based on the intersection of the ILS glide slope path (or standard path if 
no ILS) with the RI zone altitude. The example below (Figure 6) shows that with a typical zone altitude 
of 800 feet and a typical glide slope angle of 3 degrees, the end of the zone would be calculated to extend 
approximately 15,265 feet past the touchdown point. (The touchdown point is next to the ILS antenna.) 
Assuming the touchdown point is typically located 1,000 feet from the end of the runway, the zone would 
extend approximately 14,256 feet, or 2.34 nm, past the runway threshold. 

The width of RI zones is wider at the approach ends than at the runway threshold (see Figure 2) to 
allow for up to a two-dot ILS localizer deviation error on approaches. 

All values for RI zone placement can be modified in configuration files to be optimal for any airport. 
Site-specific adaptation of some values may be necessary due to conditions at individual airports. For 
example, if parallel runways are closely spaced, runway zones may need to be narrower. Airports in 
mountainous regions may require steeper glide slopes. Construction at airports may cause runway 
dimensions to change or may lead to creation of new runways or removal of existing runways. 

5.4.3 Incursion Scenarios and Alert Criteria 

RSM is designed to detect all possible runway incursion scenarios including conflicts on single 
runways, intersecting runways and intersecting flight paths. This capability is accomplished using a 
generic approach that is based on the concept of ownship and traffic operational states as defined in 
Appendix A. Conflict scenarios are defined by the combination of operational states that determine 
whether or not alert criteria should be tested for conflicts. There are separate criteria for single runway 
and intersecting runway/flight path conflicts. Appendix B describes the alert criteria and default 
thresholds and provides a set of tables that define the scenario conditions for all possible combinations of 
ownship and traffic states. 

14 



Runway Incursion Zone 



Approx. 14,265 ft 


Figure 6. Example Using 3-Degree Glide Slope to Determine Incursion Zone Ends 

5.4.4 Determining Operational States 

Since incursion scenarios and alert criteria are based on the operational states of ownship and traffic 
(Section 5.4.3 above), the correct performance of RSM depends on, among other things, how accurately 
these states are determined. The criteria and data for determining states include on or off the runway, 
heading/track in direction of runway, ground speed, acceleration, altitude and vertical speed. 

Additional data are also available for ownship states such as auto throttle, EPR mode, throttle 
position, thrust reversers, air-ground, nose wheel squat, etc. (see Appendix C and Table Cl). Ownship 
states can be computed accurately because the additional data help to indicate “intent” to takeoff, “intent” 
to land, etc. However, these intent data are not available for traffic. Although RSM has good results in 
computing traffic states without the intent data, accuracy could potentially be improved if this data 
becomes available. See discussion on intent data in Appendix D. 

5.4.5 Alert Output Data 

The current alert output parameters for the RSM TA and CA are based on the aural and graphical 
display requirements developed through simulation and flight testing that provide the flight crew with 
optimal alert awareness. The current parameters are listed in Section 4.3. Additional parameters are 
available in RSM and can be provided in future upgrades as required. 

5.5 LACM 


5.5.1 Integration with TCAS 

LACM is designed to detect and alert for air-to-air conflicts at low altitudes near the airport without 
conflicting with TCAS operation. As mentioned in Section 2.2, TCAS resolution advisories are inhibited 
below 1000 feet AGL ±100 feet and aural traffic advisories are inhibited below 500 feet AGL. LACM 
monitors for conflicts below 1000 feet AGL. Any overlap in coverage with TCAS will require 
integration and coordination so LACM does not interfere with existing TCAS operations. For example, 
LACM will not alert if TCAS is already alerting for the same traffic. Future research regarding LACM 
and TCAS integration is planned. The results of this research could possibly support RTCA SC-218 
objectives (see Section 2.2). 

5.5.2 Traffic Data and Computations 

A major difference between LACM and TCAS design is the way traffic data is acquired and the 
resulting methods of computing distance to aircraft, bearing, and closing speed. TCAS uses Mode S and 
Mode C surveillance of nearby airborne traffic at exact time intervals to continually measure the distance 


15 



(range), direction (bearing), and altitude (if available). This system provides accurate, timely, and 
consistent data to compute parameters. TCAS determines closing speed between ownship and traffic by 
interrogating nearby Mode C or Mode S transponder-equipped traffic and using the position data to 
compute changes in distance over time. 

Currently, LACM does not use TCAS Mode-S/Mode-C data directly but primarily depends on data 
available from ADS-B. (See Section 4) Closing speed is critical in determining the timing of a potential 
conflict. During previous RSM research, closing speed had been calculated using ADS-B aircraft 
position data, and the timestamps associated with that data. However, flight testing found that using 
ADS-B position reports and associated timestamps to calculate closing speeds produced erratic results 
since neither of these data items were reported with sufficient accuracy. Future upgrades to ADS-B may 
improve accuracy and timeliness; however, an immediate solution is needed. 

Another method of computing closing speed is to use ADS-B ground speeds that are consistent and 
not as dependent on time stamps as position data. By computing the components of ground speed in the 
direction of closure for both ownship and traffic, and comparing these components, the closing speeds 
and times to CPA are highly accurate and smooth (not erratic). This method of computation is currently 
used by LACM when ADS-B is the data source. 

5.5.3 Monitoring and Alert Criteria 

Since LACM is designed to operate at low altitudes, the monitoring and alert criteria and thresholds 
must be optimized to prevent nuisance and false alerts and allow sufficient lead times for evasive action 
to prevent collisions. The current alert criteria are based on those used by TCAS but thresholds may 
differ based on testing and operational requirements (e.g., approach spacing, etc.). For example, criteria 
for time to closest point of approach (range tau) and time to co-altitude (vertical tau), may have different 
thresholds for LACM, to customize the lead time for pilot response to alerts. Also, to prevent false and 
nuisance alerts, some additional LACM criteria are required such as projected separation at CPA, relative 
altitude at CPA, and position of CPA on the ground or airborne. Table 1 lists the initial monitoring 
criteria, alert criteria, and thresholds that have been determined based on developmental testing and 
evaluation. Monitoring criteria determine what traffic is monitored for conflicts, and alert criteria 
determine if and which alerts to issue. The threshold values for monitoring and alerts are contained in 
software configuration files and can be modified as required based on future testing. For a TA or CA to 
be issued, all criteria listed in the table must be satisfied. 


Table 1. Initial LACM Alert Criteria and Thresholds 


Monitoring Criteria 

Target proximity < 18000 ft from ownship position. 
Ownship and target altitudes 50 - 1000 ft AGL ±100 ft. 

Alert Criteria 

TA 

CA 

Range tau (sec) 

<35 

<20 

OR current distance to target (range) (ft) 

<2000 

<1200 

Vertical tau (sec) 

<35 

<20 

OR current relative altitude (ft) 

<1000 

<400 

OR projected relative altitude at CPA (ft) 

<1000 

<400 

Projected horizontal separation at CPA (ft) 

<2000 

<1200 

Projected ownship and/or target altitudes at CPA (ft) 
(Own/target not near the ground at CPA) 

>50 

>50 
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5.5.4 Alert Data Output 

The parameters that are output for the LACM TA and CA depend on the cockpit alerting display 
(aural and graphical) requirements for NextGen. The future alert display requirements are u nk nown at 
this time, but a list of parameters can be constructed based on previous RIPS alert output as well as 
display data currently utilized by TCAS. The following list of alert output parameters is based on 
developmental testing and evaluation but is subject to change based on future testing and requirements. 
Alert parameters previously used for RIPS are identified with asterisks. 

• *Traffic id (e.g., ICAO aircraft address) 

• *Alert code (includes type of alert TA/CA, traffic runway, traffic arr/dep state) 

• *Distance to traffic (range) 

• *Time (sec) to collision or closest point of approach (range tau) 

• Bearing 

• Traffic air or ground 

• Relative altitude (if airborne) 

• Traffic climb/descend (if airborne) 

• Time (sec) to co-altitude (vertical tau) (if airborne) 

5.6 TCM 


5.6.1 Data Accuracy 

A high degree of data accuracy on the ground is necessary because of the very close distance and time 
tolerances involved in conflict situations and the greater likelihood of false and nuisance alerting. 
Therefore, TCM data accuracy requirements are stated more explicitly than those for RSM and LACM. 
The criteria and threshold tables in the next section indicate the accommodations TCM makes for 
variations in data accuracy. 

Based on initial developmental testing, position reports for ownship and traffic are required to be 
within 3 meters, aircraft headings (yaw) to the nearest tenth of a degree, and time stamps to the nearest 
millisecond. 

Ground speed accuracy requirements are less straightforward, since reported ground speed may be 
incorrect by more than one knot, and a stationary aircraft may report a non-zero ground speed. Initial 
testing shows that ground speed should be reported to the nearest tenth of a knot at a minimum. At the 
same time, TCM allows for a discrepancy of up to two knots for reported ground speed. 

These data requirements will be validated based on future testing. 

5. 6.2 Monitoring and Alert Criteria 

Since TCM is designed to operate only when the ownship is on the ground, the monitoring and alert 
criteria and associated thresholds must be optimized for much closer tolerances than for airborne 
operations. The thresholds must be set to allow sufficient lead times to prevent collisions but minimize or 
eliminate over alerting. Table 2 lists the initial monitoring criteria, alert criteria and thresholds that have 
been determined based on developmental testing and evaluation. 

Monitoring criteria determine what traffic is monitored for conflicts, and alert criteria determine if 
and which alerts to issue. The threshold values for monitoring and alerts are contained in software 
configuration files and can be modified as required based on future testing. For a TA or CA to be issued, 
all criteria listed in the table must be satisfied. The threshold modification factors, listed in the table are 
secondary criteria that modify the standard thresholds to prevent nuisance alerting and alert toggling 
(alerts on and off or switching between TA and CA). Threshold modification factors are described in 
Table 3. 
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Table 2. Initial TCM Alert Criteria and Thresholds 


Monitoring Criteria 

Target proximity < 1500 ft from ownship position. 

Either ownship or target speed must be > 5 kts. (No alert if both stopped or both < 5 kts) 

Alert Criteria 

TA 

CA 

Threshold 

Modification Factors 

TA 

CA 

Range tau (sec) 

16 

10 

one stopped 

12 

7 

slower taxi 

12 

7 

same Direction 

12 

7 

Turning 

12 

7 

Following 

10 

7 

head-on 

16 

10 

Current distance to target (range) 
< min alert distance (ft) 

700 

400 

one stopped AND 
slower taxi 

150 

150 

turning AND 
in path 

150 

150 

Projected separation at CPA 

< min separation (ft) 

OR 

Current distance to target (range) 

< min separation (ft) 

50 

30 

one stopped 
AND slower taxi 

15 

15 

not one stopped 
AND slower taxi 
AND same Direction 
AND in path 

10 

10 

slower taxi 
AND range tau = 0 

20 

20 

CA in progress 

60 

45 

TA in progress 

60 

30 


Table 3. Initial TCM Threshold Modification Factors 


Threshold Modification 
Factors 

Description 

one stopped 

At least one aircraft is stopped or moving < 2 kts. 

slower taxi 

Both aircraft are taxiing <15 kts. (One can be stopped.) 

same direction 

Both aircraft are moving in the same direction within ±50° of heading. 

turning 

One or both aircraft is/are turning with turn rate > 3°/sec. 

following 

One aircraft is following the other and neither is stopped. 

in path 

One of the aircraft is in the path of the other, and neither is stopped 

head-on 

Both aircraft are in each other’s paths within ±20°. 


5.6.3 Alert Data Output 

The parameters that are output for the TCM TA and CA depend on the cockpit alerting display (aural 
and graphical) requirements for NextGen. The future alert display requirements are u nk nown at this time, 
but a list of parameters can be constructed based on previous RIPS alert output. The following is a list of 
initial parameters that is subject to change based on future testing and requirements. Alert parameters 
previously used for RIPS are identified with asterisks. 

• *Traffic id (e.g., ICAO aircraft address) 

• * Alert code (type alert TA/CA, traffic runway and traffic arr/dep state if applicable) 

• *Distance to traffic (range) 

• *Time (sec) to collision or closest point of approach (range tau) 

• Bearing 
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6 Initial Description of ATCAM Resolution Advisories 


6.1 Resolution Advisories (RA) 

As mentioned previously, the ATCAM initial design does not include Resolution Advisories (RA). 
This section describes how ATCAM might provide such a feature. 

A distinction must be made between an RA and an evasive maneuver. The term “evasive maneuver” 
is used to describe an action taken to avoid or mitigate a conflict. As described earlier, a TA may 
occasionally warrant an evasive maneuver, while a CA requires an evasive maneuver; in both cases, the 
evasive maneuver is currently left to the discretion of either the pilot or ATC, and ATCAM provides no 
direction. A RA, on the other hand, can be considered a CA that specifies an evasive maneuver. 

The initial model for defining conflict resolutions is TCAS RAs. ATCAM, however, encounters a 
much wider variety of potential conflicts than TCAS. Selection of resolutions under ATCAM must be 
dependent upon the individual algorithm that detects the conflict (RSM, LACM, or TCM), as well as the 
operational state within the algorithm. 

An area of high concern for any resolution is that diverting the ownship from its path does not in turn 
create a new conflict with different traffic. A related concern is the ability to detect and resolve conflicts 
with multiple traffic simultaneously, as TCAS does. 

Eventually, ATCAM must be able to coordinate RAs between multiple aircraft/vehicles equipped 
with ATCAM, as well as handle unequipped traffic. However, the RA coordination capability will be 
reserved for future consideration, and will not be addressed in this document. 

The RA concept outlined in the following sections is an initial proposal that, once prototyped, will be 
validated through various means such as qualitative pilot evaluation, automated simulation, and piloted 
simulation. 


6.2 RA Logic 

6.2.1 Processing RAs 

The flow chart in Figure 7 indicates the logic that each individual algorithm might use to process 
RAs. No integration or prioritization is made between RAs from separate algorithms. 

When the ATCAM algorithms detect a conflict, it is determined whether the conflict meets CA 
criteria. If so, the conflict is categorized according to the algorithm’s states (for example, 
arrival/departure/taxi for RSM). A CA is then issued immediately, before the RA, to allow immediate 
notification while the RA is being determined. ATCAM will issue an RA once an appropriate resolution 
is determined. 

ATCAM will continue to monitor traffic after issuing the RA. Since the pilot cannot be expected to 
implement the resolution instantly, ATCAM will maintain a “grace period” for the RA, to accommodate 
the time required for the pilot to react. ATCAM will not recommend further action to address the conflict 
until the grace period has expired. The resolution chosen may assume particular behavior on the part of 
the traffic and ownship, to resolve the conflict. If unexpected behavior is observed after the grace period 
has expired, a new RA may need to be issued. A new RA may possibly reverse the original RA (for 
example, bear left instead of bear right). TCAS only allows one reversal per conflict. Further simulation 
and analysis will determine whether such a limit is appropriate for ATCAM. 

As ATCAM continues to monitor traffic, the conflict should either mitigate or be resolved. As the 
conflict mitigates, ATCAM may issue a downgraded RA. Once the conflict resolves, the RA will be 
removed. If the conflict neither mitigates nor resolves after a suitable grace period, a new RA may need 
to be issued. 
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Figure 7. Resolution Advisory Logic for ATCAM Algorithm 















6.2.2 Determining Resolutions 

The flow chart in Figure 9 expands the logic for the “Determine Resolution” box in Figure 8. 

Once a CA has been issued, ATCAM will examine the list of potential resolutions for the conflict, 
and attempt to select an acceptable maneuver from the list. Potential resolutions may be dependent on the 
algorithm’s current state, or on the geometric relationship between the two aircraft/vehicles. 

For each potential resolution, ATCAM will calculate whether implementing the resolution will cause 
a new conflict, perhaps with different traffic in the area. This calculation will require the following steps: 

• Estimate the time necessary to perform the maneuver, 

• Project ownship’s position and heading at the end of the maneuver, 

• Project the conflicting traffic’s position and heading at the end of the maneuver, 

• Project the positions and headings of all nearby targets at the end of the maneuver, and 

• Determine if any conflicts will exist at the end of the maneuver. 

It may also be necessary to calculate projected conflicts at interim steps during the maneuver, instead 
of waiting until the end of the maneuver. Further analysis and simulation will be required to determine 
the best forecasting logic. 

If a resolution is found that does not cause a new conflict, an RA will be issued using that resolution. 
Further processing may be performed to determine whether multiple acceptable resolutions exist, and to 
determine which is most desirable among them. 

If no viable resolution is found, a “No Resolution” RA will be issued, to notify the pilot that ATC AM 
failed to determine a resolution, and that the pilot’s discretion should be used to determine a resolution for 
the CA. ( An open issue is whether RAs are best maintained separately from CAs, or whether resolutions 
should just be added as a separate field to CA.) 

Since the resolution is chosen by considering the ramifications on all nearby traffic, this method will 
address simultaneous conflicts involving multiple traffic. 



Figure 8. Resolution Determination Logic for ATCAM Algorithm 
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6.3 RSMRAs 


6.3.1 Single Runway Resolutions 

Table 4 describes an initial set of potential evasive maneuvers that may be specified by an RSM RA, 
when both aircraft are in a single runway incursion zone. 

When a CA is issued, ATCAM will attempt to select one of these evasive maneuvers to address the 
conflict. An RA specifying the evasive maneuver will then be issued, as described earlier. The 
maneuvers considered for each CA will be dependent on the set of conditions that led to the CA. These 
conditions will include at minimum the combination between ownship state and traffic state. Other 
conditions may be considered as well, such as separation distance, and whether the aircraft are moving 
toward each other. In addition to the CA conditions, additional conditions may need to be considered to 
determine an evasive maneuver, such as whether traffic is in front of the ownship or behind. 

This document currently does not state which evasive maneuvers will be selected for specific CA 
conditions. Extensive simulation will be necessary to determine a suitable set of maneuvers for RSM. 
None of the proposed resolutions for RSM provide navigational specifics, such as how sharply to turn, 
climb, or adjust velocity. Different aiiports, and different carriers, often have strict, but very different, 
procedures for aborting approach and takeoff. Also, the evasive maneuvers might be very different for 
various types of aircraft. Further analysis and simulation will be required to determine the feasibility of 
including more detailed evasive maneuvers and, if feasible, the specifics of the maneuvers. 


Table 4. Potential RSM Evasive Maneuvers 


Evasive Maneuver 

Potential Ownship States 

Description 

Go Around 

Approach, Flythru 

Terminate approach and climb away 

Go Around and Sidestep 

Approach, Flythru 

Terminate approach, sidestep runway, 
and climb away 

Sidestep 

Climbout, Flythru 

Veer to the side, continue takeoff 

Touchdown Emergency 
Stop 

Approach 

Expedite landing, stop quickly 

Reject Takeoff 

Takeoff roll 

Abort takeoff, stop 

Expedite Takeoff 

Pre-takeoff, Takeoff roll, 
Climbout 

Take off as quickly as possible 

Emergency Stop 

Taxi, Pre-takeoff, 
Rollout 

Stop immediately (severe slowdown 
may suffice) 

Exit/Clear Runway 

Taxi, Pre-takeoff, 
Takeoff roll, Rollout 

Proceed immediately to nearest 
runway exit 

Slow 

Approach, Fly-thru, 
Climbout 

Reduce speed while airborne 

Speed Up 

Fly-thru 

Increase speed while airborne 

No Resolution 


Issue CA, leave resolution to pilot 
discretion 


6.3.2 Intersecting Runway Resolutions 

When the ownship and traffic are in separate but intersecting runway incursion zones, it is expected 
that evasive maneuvers will be chosen from the same table used for single runway resolutions, above. 
However, an intersecting runway conflict might not require the same evasive maneuver as a single 
runway conflict with similar circumstances, and a different maneuver from the table might be chosen. In 
general, the conditions which cause an intersecting runway CA to be issued are more complicated than for 
single runway CAs. 

Simulation will be necessary to determine a suitable set of maneuvers for intersecting runway 
resolutions. 
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6.3.3 Advisory Data Output 

The output parameters for RSM RAs will be implemented as an enhancement to the parameters for 
RSM CAs, documented in Section 5.4.5. An additional type of advisory, Resolution, will be added to the 
existing Caution and Warning Advisories. A new code will be created to indicate the evasive maneuver 
associated with the RA. Both of these parameters will be included in the four-digit alert code, which will 
be encoded into a CPDLC-compatible format. Consequently, ATC can be informed of the resolution 
advice at the same time as the pilot. 


6.4 LACMRAs 


6.4.1 LACM Resolutions 

LACM is modeled after TCAS II, but for low altitude conflicts. TCAS II evasive maneuvers consist 
solely of vertical movements, with instructions about how steeply to ascend or descend. An enhanced 
version of TCAS has long been envisioned that includes resolutions with horizontal movements, but that 
version has not been released yet. 

Because LACM operates at low altitudes, LACM is not able to direct aircraft to descend. Thi s 
constraint does limit the options for vertical resolutions in LACM, although aircraft can still be directed to 
climb. Consequently, LACM will support horizontal evasive maneuvers and acceleration evasive 
maneuvers, in addition to vertical evasive maneuvers. 

Tables 5 a through 5d describe an initial set of potential evasive maneuvers that may be specified by 
an LACM RA. Tables 5a, 5b, and 5c provide specific maneuvers for each dimension, while Table 5d 
provides a template for combining maneuvers in the three different dimensions. 


Table 5a. Potential LACM Vertical Evasive Maneuvers 


Evasive 
Maneuver (V) 

Navigational 
Data (v) 

Description 

Climb 

TBD 

Climb at a rate of TBD feet per minute (fpm). 

Do Not 
Descend 

TBD 

Do not descend at a rate greater than TBD fpm. If already 
descending past that rate, reduce descent rate to TBD or less. 

Do Not Climb 

TBD 

Do not climb at a rate greater than TBD fpm. If already 
climbing past that rate, reduce climb rate to TBD or less. 

Level Off 


Level off vertically to neither climb nor descend. (Same as 
Climb at 0 fpm, or Do Not Descend at 0 fpm, or Do Not 
Climb at 0 fpm.) 

No Vertical 
Maneuver 


Maintain current vertical trajectory. 


Table 5b. Potential LACM Horizontal Evasive Maneuvers 


Evasive 
Maneuver (H) 

Navigational 
Data (h) 

Description 

Bear Right 

TBD 

Bear to the right by TBD degrees. If already bearing right by 
more than TBD degrees, reduce turn angle to TBD degrees. 

Bear Left 

TBD 

Bear to the left by TBD degrees. If already bearing left by 
more than TBD degrees, reduce turn angle to TBD degrees. 

No Horizontal 
Maneuver 


Maintain current horizontal trajectory. 
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Table 5c. Potential LACM Acceleration Evasive Maneuvers 


Evasive 
Maneuver (A) 

Navigational 
Data ( a ) 

Description 

Slow 

TBD 

Reduce speed by TBD knots 

Speed 

TBD 

Increase speed by TBD knots 

No Acceleration 
Maneuver 


Maintain current velocity. 


Table 5d. Potential LACM Evasive Maneuver Combinations 


Evasive 

Maneuver 

Navigational 

Data 

Description 

V-.H-.A 

v.h'.a 

Perform a combination of: 

• Vertical maneuver V, with navigational data v, 

• Horizontal maneuver H , with navigational data h, and 

• Acceleration maneuver A, with navigational data a. 

No Resolution 


Issue CA, leave resolution to pilot discretion 


The “Navigational Data” field has different meanings for different dimensions. This field contains 
some quantification of the degree by which the ownship should alter its course. For vertical maneuvers, 
the Navigational Data is the required vertical rate (in feet per minute, or fpm), for horizontal maneuvers it 
is the angle (in degrees) by which to turn, and for acceleration maneuvers it is the amount (in knots) by 
which the velocity should be changed. Simulation will help determine the appropriate measures for these 
fields. 

Like TCAS, and unlike RSM, the LACM conflict criteria utilize no real operational state information, 
but merely indicate that the two aircraft will pass too closely to each other. (LACM may in some 
instances have access to RSM state information, but such information may not be relevant to low altitude 
conflicts, even when available.) Without such operational state information, determining potential 
resolutions for the conflict requires further analysis. 

TCAS only allows the option of vertical maneuvers, and chooses the least-disruptive maneuver that 
will provide the most vertical separation. LACM, however, must support maneuvers in multiple 
dimensions, as described previously. So comparing separations between resolutions becomes more 
complicated. 

An alternate approach for choosing potential evasive maneuvers might be to compare the ownship’ s 
position at CPA with the traffic’s position at CPA, and choose a maneuver that increases whatever 
separation is already expected to exist. For example, if the ownship will be above and to the right of the 
traffic at CPA, the most likely maneuver to choose might be a combination of Climb and Bear Right. A 
similar approach has been developed for conflict resolution as part of distributed air/ground traffic 
management research for the en-route environment [Ballin, et. al., 2002, Hoekstra, et. al., 2002]. 

Potential evasive maneuvers should potentially be prioritized according to the following criteria, in 
descending order: 

• Avoid the conflict. 

• Avoid creating new conflicts. 

• Avoid crossing flight paths. 

• Minimize disruption to ownship ’s current flight path. 

6.4.2 Advisory Data Output 

The output parameters for LACM RAs will be implemented as an enhancement to the parameters for 
LACM CAs, documented in Section 5.5.4. An additional type of advisory, Resolution, will be added to 
the Caution and Warning alerts. A new code will be created to indicate the evasive maneuver associated 
with the RA. Navigation instructions, such as vertical rates, may be included in the evasive maneuver 
codes, or they may require additional fields. All of these parameters will be included in the four-digit 
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alert code, which will be encoded into a CPDLC-compatible format. Consequently, ATC can be 
informed of the resolution advice at the same time as the pilot. 

6.5 TCMRAs 


6.5.1 TCM Resolutions 

Table 6 describes an initial list of potential evasive maneuvers that may be specified by a TCM RA. 


Table 6. Potential TCM Evasive Maneuvers 


Taxi Evasive Maneuver 

Description 

Emergency Stop 

Stop immediately (severe 
slowdown may suffice) 

Slow down 

Reduce taxi speed 

Speed Up 

Increase taxi speed 

Turn Right 

Turn sharply to right 

Turn Left 

Turn sharply to left 

No Resolution 

Issue CA, leave resolution to 
pilot discretion 


Similar to LACM, the TCM conflict criteria utilize little operational state information, but merely 
indicate that the two aircraft will pass too closely to each other. Determination of TCM resolutions may 
be similar to determination of LACM resolutions, and may be based on relative positions at CPA between 
ownship and traffic. A difference, however, is that TCM will not generate vertical RA maneuvers since 
the aircraft is on the airport surface during taxi operations. 

Potential evasive maneuvers for TCM should be prioritized according to the same criteria as stated for 
LACM. 

6.5.2 Advisory Data Output 

The output parameters for TCM RAs will be implemented as an enhancement to the parameters for 
TCM CAs, documented in Section 5.6.3. An additional type of advisory, Resolution, will be added to the 
Caution and Warning advisories. A new code will be created to indicate the evasive maneuver associated 
with the RA. Both of these parameters will be included in the four-digit alert code, which will be 
encoded into a CPDLC-compatible format. Consequently, ATC can be informed of the resolution advice 
at the same time as the pilot. 


7 Summary 

NASA is conducting research to enable safe airport operations for both current and future NextGen 
operations. Aircraft-based conflict detection and alerting algorithms (known as the Airport Traffic 
Collision Avoidance Monitor (ATCAM)) are being developed to detect potential traffic conflicts in the 
terminal area and generate alerts that can be displayed to the pilot. 

ATCAM is comprised of three separate but integrated algorithms that operate at low altitudes near the 
airport, on the runway, and during taxi and ramp operations for multiple classes of aircraft as well as 
surface vehicles. The Runway Safety Monitor (RSM) detects runway incursion conflicts and generates 
alerts that provide the flight crew with sufficient awareness to take action to avoid a collision. RSM has 
been under development and testing for many years and has proven be effective in reducing all types of 
runway incursions and eliminating the most severe incursions. The Low Altitude Conflict Monitor 
(LACM) detects and alerts for air-to-air conflicts at low altitudes near the airport without conflicting with 
TCAS. The Taxi Conflict Monitor (TCM) detects and alerts for ground taxi conflicts anywhere in the 
airport movement and ramp areas. LACM and TCM are in the early stage of development; however, 
developmental testing has proved to be very promising for elimination of collisions in these operating 
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areas. The technical approach for each of these algorithms are presented in this report along with the data 
communications that are necessary for successful implementation and integration. 

Work is currently in progress to test and refine the algorithms as part of NextGen research. This work 
is also being closely coordinated with other NASA research in emerging NextGen technologies including 
synthetic and enhanced vision systems and airborne precision spacing. On-going surface safety research 
also includes determination of feasibility and development of requirements for the addition of conflict 
resolution advisories to warning alerts. Results of this research and changes to requirements will be 
provided in updates to this report. 
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Appendix A - RSM Operational States 


The ownship (O) and traffic (T) operational states used by RSM are defined as follows: 


taxi state: 
pre-takeoff state: 

takeoff roll state: 
climb-out state: 
approach state: 
rollout state: 
fly-thru state: 


Aircraft/vehicles taxiing or stopped and stationary obstacles or equipment. 
Ownship positioned for takeoff but before or at the beginning of takeoff roll. 
(This state is not available for traffic.) 

Ground takeoff roll in progress, not airborne. 

Airborne climb out after takeoff roll or after an aborted landing. 

Airborne on final approach. 

Ground roll out after landing or after an aborted takeoff. 

Flying through or crossing the RI zone but not landing or taking off. Includes 
turning from the runway heading during departure climb out or go-around 


The operational states are determined using the criteria described in the tables below. Table A1 
describes the criteria used to determine ownship operational states, supplemented by the ownship takeoff 
mode criteria described in Table A2. Table A3 describes the criteria used to determine traffic operational 
states. Table A4 details how the criteria from Tables A1 and A3 are used to define each operational state. 


The threshold parameters listed in these tables are customizable via configuration files. The ownship 
parameters can be configured differently for each type of ownship aircraft, while the traffic parameters 
are applied generically to all traffic aircraft. The threshold values listed under “Default Thresholds” 
should be considered examples, and can be adjusted as necessary. The general aviation thresholds under 
“GA” are untested estimates, and are expected to be refined based on future simulation and flight testing. 


Table Al. Ownship Operational State Criteria & Default Thresholds 


Operational State Criteria - Ownship 

Code 

Description * 

Default Threshold 

GA** 

Non-GA 

A 

Altitude above ground level (ft) <= 0 

NA 

NA 

B 

All wheels on the ground (true/false) 

NA 

NA 

C 

Ground speed <= taxi high speed (knots) 

20 

40 

D 

Aircraft is on the runway 

NA 

NA 

E 

True heading differs from runway zone tme heading <= heading 
tolerance (degrees) 

10 

10 

F 

In takeoff mode (true/false), from Table A2: 

FI or (F2 and F7) or ((F3 or F4) and F5) or (C and F8) or ((not C) and F6) 

NA 

NA 

G 

Vertical speed > minimum elimb-out vertical speed (ft/min) 

60 

60 

H 

Distance from ownship position to end of runway >= approx land rollout 
distance for type of landing (ft) (able to stop before end of runway) 

2000 

6000 


* Text in bold indicates parameters specified under “Default Threshold”. 
** GA thresholds have not been verified through testing. 
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Table A2. Ownship Takeoff Mode Criteria & Default Thresholds 


Takeoff Mode Criteria - Ownship 

Code 

Description * 

Default Threshold 

GA** 

Non-GA 

FI 

EPR mode set (tme/false) 

NA 

NA 

F2 

Auto throttle engaged (tme/false) 

NA 

NA 

F3 

Throttle position >= takeoff throttle position (degrees)(non-GA) 

- 

90 

F4 

Throttle position is at full forward GA 

NA 

- 

F5 

Track acceleration > 0.0G 

NA 

NA 

F6 

Track acceleration >= 0. 1G 

NA 

NA 

F7 

Track acceleration > 0. 1G 

NA 

NA 

F8 

Track acceleration >= takeoff acceleration (G) 

0.2 

0.2 


Table A3. Traffic Operational State Criteria & Default Thresholds 


Operational State Criteria - Traffic 

Code 

Description * 

Default Threshold 

GA** 

Non-GA 

I 

Altitude above ground level (ft) <= 0 

NA 

NA 

J 

Aircraft is on the runway 

NA 

NA 

K 

True heading differs from runway zone true heading <= heading 
tolerance (degrees) 

10 

10 

L 

Ground speed <= taxi high speed (knots) 

20 

40 

M 

Ground speed >= taxi low speed (knots) 

4 

4 

N 

Ground speed > minimum start takeoff speed for traffic (knots) 

15 

15 

O 

Acceleration >= minimum start takeoff acceleration for traffic 
(knots/sec) 

3 

3 

P 

Acceleration > minimum takeoff acceleration for traffic 
(knots/sec) 

0.1 

0.1 

Q 

Vertical speed > minimum climb-out vertical speed for traffic 
(ft/min) 

60 

60 

R 

Distance from traffic position to end of runway >= maximum 
traffic rollout distance (ft) (able to stop before end of runway) 

2000 

6000 
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Table A4. Operational State Definitions 


Operational State 

Ownship Criteria 

Traffic Criteria 

Taxi/Stationary 
(on or near rwy) 

A and B and C and 

((not D) or (not E) or (not F)) 

I and L and M and J and K and 
((not N) or (not O)) 

I and L and M and ((not J) or (not K)) 

I and L and (not M) 

A and B and 

(not C) and ((not D) or (not E)) 

I and (not L) and ((not J) or (not K)) 

Pre-takeoff 

A and B and C and D and E and F 

NA 

Takeoff roll 

A and B and (not C) and D and E and F 

I and L and M and J and K and N and O 

I and (not L) and J and K and P 

Climb-out 

((not A) or (not B)) and E and G 

(not L) and K and Q 

((not A) or (not B)) and E and 
(not G) and (not FI) 

(not L) and K and (not Q) and (not R) 

Approach 

((not A) or (not B)) and D and 
(not G) and FI 

(not L) and K and (not Q) and R 

Rollout 

A and B and (not C) and D and E and 
(not F) 

I and (not L) and J and K and (not P) 

Fly-thru RI Zone 

((not A) or (not B)) and (not E) 

(not L) and (not K) 
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Appendix B - RSM Scenarios and Alert Criteria 


This appendix describes in detail the scenarios, alert criteria, and thresholds used by RSM to issue 
Traffic Advisories (TA) and Conflict Advisories (CA) (see Sections 3.1.1 and 3.1.2). The alert criteria 
and default thresholds are listed separately for conflicts on single runways (Table Bl) and conflicts on 
intersecting runways or intersecting flight paths (Table B2). An intersecting flight path occurs when 
runway incursion (RI) zones intersect before or beyond the runway boundary (see Section 3.2). The 
default thresholds for alert criteria are implemented as parameters that are contained in software 
configuration files. The default values for CA thresholds were determined through simulation and flight 
testing, but can be modified as required based on future research. The default values for TA thresholds 
are untested estimates, and are subject to change based on future simulation and flight testing. Previous 
testing [Jones 2002, Jones and Prinzel 2006] revealed that TAs were only effective/desirable when the 
ownship was in the approach state, or when the ownship was in position and hold and the traffic was 
approaching the same runway. Therefore, TAs are only implemented for two types of scenarios: (i) 
ownship state is approach, or (ii) ownship state is taxi or pre-takeoff, and traffic state is approach. 

The tables B3 - B9 define the scenarios for each combination of ownship and traffic states for both 
single and intersecting runway/flight path conditions and list the alert criteria associated with each 
scenario from the appropriate criteria table (Bl or B2). RSM detects and issues alerts for runway 
conflicts only when both the ownship aircraft and traffic are inside Rl zones and below the zone altitude. 
For single runway scenarios, traffic is defined as other aircraft, vehicles, obstacles or equipment inside the 
same RI zone as the ownship aircraft. For intersecting zone scenarios, traffic is defined as other aircraft 
departing, arriving, or taxiing inside the RI zone that intersects the ownship RI zone. Traffic position and 
other traffic data must be available via data link to the ownship aircraft (see Section 4.2). 
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Table Bl. Alert Criteria & Default Thresholds for Single Runway Scenarios 


Alert Criteria - Single Runway Scenarios 
(Assumes Ownship and Traffic are inside the same runway incursion zone) 

Code 

Description * 

Default Threshold 

GA 

Non-GA 

TA** 

CA 

ta** 

CA 

A 

Alert immediately at any distance 

NA 

NA 

NA 

NA 

B 

O/T < minimum horizontal separation threshold (ft) 

6000 

4500 

8000 

6000 

C 

O/T < close horizontal separation (ft) (lower separation 
threshold for some scenarios) 

** 

700 

** 

700 

D 

Distance from rwy threshold of aircraft taxiing or stopped on rwy 

is < approx land rollout distance for type of landing aircraft 
(ft) 

2000 

2000 

6000 

6000 

E 

Aircraft rolling out not able to stop before aircraft taxiing or 
stopped on runway 

** 

NA 

** 

NA 

F 

Ownship distance to runway threshold or traffic position < 

airborne alert distance (ft) 

(airborne alert dist based on approx ownship landing speed, e.g., 
B-757 6000 ft for CA, 8000 ft for TA) 

Per 

own 

landing 

speed 

Per 

own 

landing 

speed 

Per 

own 

landing 

speed 

Per 

own 

landing 

speed 

G 

Ownship time to runway threshold or traffic position < alert time 
threshold (sec) 

40 

30 

40 

30 

H 

Ownship distance to traffic position < 2.0 times the airborne 
alert distance (ft) 

(increased airborne alert dist required for some scenarios, e.g., B- 
757 12000 ft for CA, 16000 ft for TA) 

Per 

own 

landing 

speed 

Per 

own 

landing 

speed 

Per 

own 

landing 

speed 

Per 

own 

landing 

speed 

I 

Arriving aircraft past the runway threshold 

NA 

NA 

NA 

NA 

J 

O/T current or projected closest altitude separation < minimum 
air-to-air altitude separation (ft) 

1000 

850 

1000 

850 

K 

O/T current or projected closest vertical separation < minimum 
air-to-ground vertical separation when one aircraft is on the 
ground (ft) 

** 

400 

** 

400 


* Text in bold indicates parameters specified under ‘‘‘Default Threshold”. 

** TA thresholds will only be applied for single runway scenarios of taxi/approach, pre -takeoff/ approach, or any 
ownship approach scenario. 
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Table B2. Alert Criteria & Default Thresholds for Intersecting Runway/Flight Path Scenario 


Alert Criteria - Intersecting Runway and Flight Path Scenarios 


(Assumes Ownship and Traffic are inside intersecting RI zones and not past the zone intersection) 


Code 

Description * 

Default Thr eshold 

GA 

Non-GA 

TA** 

CA 

ta** 

CA 

L 

Alert immediately at any distance 

NA 

NA 

NA 

NA 

M 

Current O/T difference in separation from intersection is < min 

separation threshold (ft) 

6000 

4500 

8000 

6000 

N 

Current O/T difference in separation from intersection is < 0.5 

times the min separation (ft) 

3000 

2250 

4000 

3000 

O 

Projected O/T closest separation at the intersection is < 

minimum separation threshold (ft) 

6000 

4500 

8000 

6000 

P 

Projected O/T closest separation at the intersection is < 0.5 

times the min separation (ft) 

3000 

2250 

4000 

3000 

Q 

Ownship distance to runway threshold < airborne alert 
distance (ft) 

(airborne alert dist based on approx ownship landing speed, e.g., 
B-757 6000 ft for CA, 8000 ft for TA) 

Per 

own 

landing 

speed 

Per 

own 

landing 

speed 

Per 

own 

landing 

speed 

Per 

own 

landing 

speed 

R 

Ownship distance to intersection < airborne alert distance (ft) 
(airborne alert dist based on approx ownship landing speed, e.g., 
B-757 6000 ft for CA, 8000 ft for TA) 

Per 

own 

landing 

speed 

Per 

own 

landing 

speed 

Per 

own 

landing 

speed 

Per 

own 

landing 

speed 

S 

Distance from touchdown to intersection for landing aircraft is < 

approx land rollout distance for type aircraft (ft) 

2000 

2000 

6000 

6000 

T 

Aircraft rolling out is not able to stop before intersection 

NA 

NA 

NA 

NA 

U 

Aircraft rolling out is < close distance to the intersection (ft) 

700 

700 

700 

700 

V 

O/T current or projected closest air-to-air altitude separation is < 

minimum airborne altitude separation threshold (ft) 

1000 

850 

1000 

850 

w 

O/T current or projected closest air-to-ground vertical separation 

is < minimum air-ground separation threshold (ft) 

400 

400 

400 

400 


* Text in bold indicates parameters specified under ‘‘‘Default Threshold”. 

** TA thresholds will only be applied for intersecting runway scenarios in which the ownship state is approach. 
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Table B3. Scenario Conditions and Alert Criteria - Ownship in Taxi State 


Ownship (0) State - Taxi On or Near Runway (Inside RI zone) 

Traffic (T) State 

Single Runway 

Intersecting Runways and RI Zones 

Scenario Conditions 

Alert Criteria 

Scenario Conditions 

Alert Criteria 

Taxi/Stationary 

Disabled for RSM scenarios 
(Taxi conflicts are 
monitored by TCM) 

— 

Not defined for 
ownship taxi 
scenarios 

— 

Pre -takeoff 

NA (Traffic pre-takeoff 
state not avail in current 
version) 

— 

— 

— 

Takeoff roll 

0 in path of T and closing 

A 

— 

— 

Climb-out 

O/T Closing 

B and K 

— 

— 

Approach 

O/T Closing 

(B or G) and D (CA) 
D (TA)* 

— 

— 

Rollout 

O/T Closing 

(E or C) 

— 

— 

Fly-thru RI 
Zone 

Not defined; alerts not 
issued 

— 

— 

— 


* Criteria B and G are not applied for TAs in this scenario. 
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Table B4. Scenario Conditions and Alert Criteria - Ownship in Pre-takeoff State 


Ownship (0) State - Pre-takeoff 

Traffic (T) State 

Single Runway 

Intersecting Runways and RI Zones 

Scenario Conditions 

Alert Criteria 

Scenario Conditions 

Alert Criteria 

Taxi/Stationary 

T in path of O 

A 

Not defined for traffic taxi 
scenarios 

— 

Pre-takeoff 

NA (Traffic pre-takeoff 
state not avail in current 
version) 

— 

— 

— 

Takeoff roll 

T in path of O 

A 

Intersect before end of 0 rwy 

L 

T behind 0 and closing 

A 

fntersect beyond end of 0 
rwy 

M or 0 

Climb-out 

O/T same heading & rwy 

B and K 

Intersect before end of 0 rwy 

L 

0/T head-on, opposite 
rwys 

A 

fntersect beyond end of 0 
rwy 

W and (M or 
O) 

Approach 

O/T same heading & rwy 
and T behind O 

B or G (CA) 
A (TA)* 

Intersect before end of 0 rwy 

s 

O/T same heading & rwy 
and T in path of 0 

B (CA)* 

fntersect beyond end of 0 
rwy 

S and (M or 
O) 

O/T head-on, opposite 
rwys 

B or G (CA) 
A (TA)* 

Rollout 

T in path of O 

A 

Intersect before end of 0 rwy 

(T or U) 

T behind 0 and closing 

B 

fntersect beyond end of 0 
rwy 

(T or U) and 
(M or O) 

Fly-thru RI 
Zone 

Closing 

B and K 

Not defined for traffic fly- 
thru scenarios 

— 


* Criteria B and G are not applied for TAs in this scenario. 
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Table B5. Scenario Conditions and Alert Criteria - Ownship in Takeoff roll State 


Ownship (0) State - Takeoff roll 

Traffic (T) State 

Single Runway 

Intersecting Runways and RI Zones 

Scenario Conditions 

Alert Criteria) 

Scenario Conditions 

Alert Criteria 

Taxi/Stationary 
(on or near rwy) 

T in path of 0 and 
closing 

A 

Not defined for traffic taxi 
scenarios 

— 

Pre -takeoff 

NA (Traffic pre-takeoff 
state not avail in current 
version) 

— 

— 

— 

Takeoff roll 

O/T same heading & rwy 

B 

O able to abort takeoff 

L 

0/T head-on, opposite 
rwys 

A 

0 not able to abort takeoff 

N or P 

Climb-out 

O/T same heading & rwy 

B 

O able to abort takeoff 

W 

O/T head-on, opposite 
rwys 

A 

0 not able to abort takeoff 

N or P 

Approach 

O/T same heading & rwy 
and T behind O 

B 

O able to abort takeoff and 
intersect before end of 0 
rwy 

S 

O/T same heading & rwy 
and T in path of 0 

A 

O able to abort takeoff and 
intersect beyond end of 0 
rwy 

S and (M or O) 

O/T head-on, opposite 
rwys 

A 

0 not able to abort takeoff 

S and (N or P) 

Rollout 

O/T same heading & rwy 
and T in path of 0 

A 

O able to abort takeoff and 
intersect before end of 0 
rwy 

(T or U) 

O/T same heading & rwy 
and T behind O and 
closing 

B 

O able to abort takeoff and 
intersect beyond end of 0 
rwy 

(T or U) and 
(M or O) 

O/T head-on, opposite 
rwys 

A 

0 not able to abort takeoff 

(T or U) and 
(N or P) 

Fly-thru RI Zone 

Closing 

B and K 

Not defined for traffic fly- 
thru scenarios 

— 
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Table B6. Scenario Conditions and Alert Criteria - Ownship in Climb-out State 


Ownship (0) State - Climb-out 

Traffic (T) State 

Single Runway 

Intersecting Runways and RI Zones 

Scenario Conditions 

Alert Criteria 

Scenario Conditions 

Alert Criteria 

Taxi/Stationary 

O/T closing 

K and (F or G) 

Not defined for traffic 
taxi scenarios 

— 

Pre-takeoff 

NA (Traffic pre-takeoff 
state not avail in current 
version) 

— 

— 

— 

Takeoff roll 

O/T same heading & 
rwy 

B 

All conditions 

W and R and 
(M or O) 

O/T head-on, opposite 
rwys 

A 

Climb-out 

O/T same heading & 
rwy 

B 

All conditions 

R and (M or 
O) 

O/T head-on, opposite 
rwys 

(I or H) 

Approach 

O/T same heading & 
rwy 

B 

All conditions 

V and S and 
R and 
(N or P) 

O/T head-on, opposite 
rwys 

J and (I or FI) 

Rollout 

O/T same heading & 
rwy and T in path of 0 

K and G 

All conditions 

W and (N or 
P) and 
R and (T or 
U) 

O/T same heading & 
rwy and T behind 0 and 
closing 

K and B 

O/T head-on, opposite 
rwys 

K and (I or FI) 

Fly-thm RI Zone 

O/T closing 

B and J 

Not defined for traffic 
fly-thru scenarios 

— 
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Table B7. Scenario Conditions and Alert Criteria - Ownship in Approach State 


Ownship (O) State - Approach 

Traffic (T) State 

Single Runway 

Intersecting Runways and RI Zones 

Scenario Conditions 

Alert Criteria 

Scenario Conditions 

Alert Criteria 

Taxi/Stationary 

Closing 

D and (F or G) 

Not defined for traffic 
taxi scenarios 

— 

Pre-takeoff 

NA (Traffic pre-takeoff 
state not avail in current 
version) 

— 

— 

— 

Takeoff roll 

O/T same heading & 
rwy 

B 

All conditions 

S and (N or P) 
and 

(Q or R) 

O/T head-on, opposite 
rwys 

A 

Climb-out 

O/T same heading & 
rwy 

J and B 

All conditions 

S and V and 
(N or P) and 
(Q or R) 

O/T head-on, opposite 
rwys 

J and (FI or I) 

Approach 

O/T same heading & 
rwy 

B 

All conditions 

S and (N or P) 
and 

(Q or R) 

O/T head-on, opposite 
rwys 

(H or I) 

Rollout 

O/T same heading & 
rwy 

G 

All conditions 

S and (T or U) 
and 

(Q or R) 

O/T head-on, opposite 
rwys 

A 

Fly-thru RI Zone 

O/T closing 

B and J 

Not defined for traffic 
fly-thru scenarios 

— 
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Table B8. Scenario Conditions and Alert Criteria - Ownship in Rollout State 


Ownship (0) State - Rollout 

Traffic (T) State 

Single Runway 

Intersecting Runways and RI Zones 

Scenario Conditions 

Alert Criteria 

Scenario Conditions 

Alert Criteria 

Taxi/Stationary 

O/T closing 

E or C 

Not defined for traffic 
taxi scenarios 

— 

Pre-takeoff 

NA (Traffic pre-takeoff 
state not avail in current 
version) 

— 

— 

— 

Takeoff roll 

O/T same heading & 
rwy and T ahead of O 

B 

All conditions 

(T or U) 

O/T same heading & 
rwy and T behind O 

A 

O/T head-on and 
opposite rwys 

A 

Climb-out 

O/T same heading & 
rwy and T behind O 

K and B 

All conditions 

W and (M or 
O) and 
(T or U) 

O/T same heading & 
rwy and T ahead of O 

K and B 

O/T head-on, opposite 
rwys 

K and (I or 
H) 

Approach 

O/T same heading & 
rwy (T behind or ahead) 

B 

All conditions 

S and (T or U) 

O/T head-on, opposite 
rwys 

A 

Rollout 

O/T same heading & 
rwy 

B 

All conditions 

(T or U) 

O/T head-on, opposite 
rwys 

A 

Fly-thru RI Zone 

O/T closing 

B and K 

Not defined for traffic 
fly-thru scenarios 

— 
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Table B9. Scenario Conditions and Alert Criteria - Ownship in Fly-thru RI Zone State 


Ownship (0) State - Fly-thru Rl Zone 

Traffic (T) State 

Single Runway 

Intersecting Runways and RI Zones 

Scenario Conditions 

Alert Criteria 

Scenario Conditions 

Alert Criteria 

Taxi/Stationary 

Incursion scenario not 
defined; alerts not issued 

— 

Not defined for ownship 
fly-thru scenarios 

— 

Pre-takeoff 

NA (Traffic pre-takeoff 
state not avail in current 
version) 

— 

— 

— 

Takeoff roll 

Closing 

B and K 

— 

— 

Climb-out 

Closing 

B and J 

— 

— 

Approach 

Closing 

B and J 

— 

— 

Rollout 

Closing 

B and K 

— 

— 

Fly-thru RI Zone 

Incursion scenario not 
defined; alerts not issued 

— 

— 

— 


42 




Appendix C - Flight Data Requirements 

This appendix lists the flight data that is currently used by the ATCAM software. Table Cl lists the 
ownship data, while Table C2 lists the traffic data. 


Table Cl. Ownship Data Parameters 


DESCRIPTION 

BINARY 

RANGE 

UNITS 

POSITIVE 

REFERENCE 

MINIMUM 

UPDATE 

RATE 

Update counter 


NA 

Always Positive 

10 HZ 

Standard time in GMT 

0 to 86,400 

Sec 

Seconds from Midnight 

10 HZ 

Scaled GPS/INS blended latitude 

+/-90 

Deg 

North from 0 

10 HZ 

Scaled GPS/INS blended long 

+/-180 

Deg 

East from 0 

10 HZ 

GPS/INS blended altitude-feet MSL 

+/-32J68 

Feet 

Above Touchdown 

10 HZ 

Geoid Separation Corrected Hybrid GPS 
Alt. 

+/-32,768 

Feet 

Above Touchdown 

10 HZ 

Corrected Barometric Altitude - 4 sources 

+/-32,768 

Feet 

Above Sea Level 

10 HZ 

Radar Altitude 

+/-32,768 

Feet 

Above Touchdown 

10 HZ 

Ground Speed 

0 - 4096 

Knots 

Always Positive 

10 HZ 

Vertical Speed 

+/- 19,384 

Ft/Min 

Up 

10 HZ 

True Heading 

+/-180 

Deg 

CW from North 

10 HZ 

Yaw Rate 

+/-128 

Deg/Sec 

Nose Right 

10 HZ 

Track Angle (True) 

+/-180 

Deg 

CW from North 

10 HZ 

Along Track Acceleration 

+/-4 

G's 

Forward 

10 HZ 

Throttle Position/Power Lever Angle - left 
(non-GA) 

+/-180 

Deg 

Forward Thrust 

10 HZ 

Throttle Position/Power Lever Angle - right 
(non-GA) 

+/-180 

Deg 

Forward Thrust 

10 HZ 

Throttle Position (GA) 

Discrete 

NA 

1 = Full Open 

10 HZ 

Reverser isolation valves 

Discrete 

NA 

l=Reverse Thrust 

10 HZ 

Air Ground Discrete 

Discrete 

NA 

l=Main Gear on Grnd 

10 HZ 

Nose Wheel Squat 

Discrete 

NA 

l=Nose Wheel on Grnd 

10 HZ 

Go Around Discrete 

Discrete 

NA 

l=Go Around Engaged 

10 HZ 

Auto-throttle Engaged 

Discrete 

NA 

l=Engaged 

10 HZ 

Decision Speed 

0-512 

Knots 

Always Positive 

10 HZ 

GPS Hybrid Position Status 

Discretes 

NA 

0=good 

10 HZ 
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Table C2. Traffic Data Parameters 



BINARY 


POSITIVE 

UPDATE 

DESCRIPTION 

RANGE 

UNITS 

REFERENCE 

RATE 

# Traffic/Intruders 

0-64 

NA 

Always Positive 

1-2 HZ 

Traffic Update Counter 


NA 

Always Positive 

1-2 HZ 

24 bit ICAO address or unique intruder id 

0-32 

NA 

NA 

1-2 HZ 

intruder flight or tail number 

Character field 

NA 

NA 

1-2 HZ 

A/C category (A380, B757, etc.) 

0-7 

NA 

NA 

1-2 HZ 

A/C type (if known) 

Character field 

NA 

NA 

1-2 HZ 

Latitude 

+/-90 

Deg 

North from 0 

1-2 HZ 

Longitude 

+/-180 

Deg 

East from 0 

1-2 HZ 

Altitude MSL 

+/-32,768 

Feet 

Above Mean Sea Level 

1-2 HZ 

Radar Altimeter 

+/-32,768 

Feet 

Above Touchdown 

1-2 HZ 

Ground Speed 

0-32,768 

Knots 

Always Positive 

1-2 HZ 

True Track (airborne) or Heading (on ground) 

+/-180 

Deg 

CW from North 

1-2 HZ 

Vertical Speed 

+/- 19,384 

Ft/Min 

Up 

1-2 HZ 

Track Acceleration 

+/-4 

G’s 

Forward 

1-2 HZ 

Slant Range 


NM 

Always Positive 

1-2 HZ 

Bearing 

+/-180 

Deg 

CW from Ownship 

1-2 HZ 

Relative Altitude 

+/-32768 

Feet 

Above Ownship 

1-2 HZ 

Traffic Acquisition in msec GMT 

0 to 86,400,000 

Msec 

Always Positive 

1-2 HZ 
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Appendix D - Surveillance Discussion 


D.l Surveillance Performance 

Requirements for ground based surveillance systems have been proposed. As mentioned above, 
ICAO proposed operational requirements for A-SMGCS, which includes surveillance performance 
requirements [ICAO 1997]. A prototype A-SMGCS architecture was evaluated during a flight test at 
ATL [Jones and Young 1998] and observed performance was compared against the A-SMGCS 
requirements [Young 1998]. 

More recently, the European Organization for Civil Aviation Equipment (EURO CAE) has proposed 
surveillance performance requirements for a Level 2 A-SMGCS that will be expected to monitor the 
airport surface and provide alerts to users when hazardous situations occur, such as runway incursions 
[EUROCAE 2007]. These requirements are listed in Table Dl. 

The FAA is in the process of deploying ADS-B throughout the National Airspace System (NAS). A 
Notice of Proposed Rulemaking (NPRM) [FAA July 2007] has been developed to propose ADS-B Out 
performance requirements to support ATC service. Although the FAA is not mandating ADS-B In at this 
time, the NPRM includes a discussion of potential ADS-B In applications and accuracy requirements. 
The NPRM proposes that a horizontal accuracy of 30 meters (98.4 feet) and a vertical accuracy of 45 
meters (147.6 feet) are sufficient to enable certain applications on the airport surface, such as traffic 
alerting. More analysis is needed to determine whether these proposed accuracies are really sufficient for 
conflict detection. 

As part of the RTCA SC-186 WG1 subcommittee, Mitre Corporation is in the process of conducting 
analysis to determine the surveillance accuracy requirements for the traffic conflict detection application. 


Table Dl. EUROCAE A-SMGCS Surveillance Performance Requirements 


Performance Parameter 

Level 2 System Requirement 

Probability of target detection 

> 99.9% on maneuvering area 

> 98% on apron 

Probability of false target detection 

< 1 0~ 3 per report 

Probability of identification 

> 99.9% on maneuvering area 

> 98% on apron 

Probability of false identification 

< 10' 3 per report 

Reported position accuracy 

< 7.5 meters (95%) on maneuvering area 
<12 meters (95%) on apron 

Reported velocity accuracy 

Speed < 5 meters/second. Direction - 

consistent with use in alerting algorithms 

Target report update rate 

At least 1 per second 

Position renewal time out period 

< 4 seconds 

Identification renewal time out period 

< 20 seconds 

Track continuity 

> 99.8% on maneuvering area 

> 98% on apron 

Target report position resolution 

<1 meter 

Target report velocity resolution 

<0.25 meter/second 

Target report time resolution 

< 0.1 second 
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D.2 Intent Data 


ADS-B provides a minimal set of data for airport traffic. Historically, the RSM algorithm has had 
good results in computing traffic states, utilizing the currently available data from ADS-B, however, 
knowledge of traffic intent could potentially provide a more accurate assessment of traffic state and result 
in more precise conflict detection with reduced false, missed, and nuisance alerts. Some intent data 
currently specified for ADS-B involve intent to change trajectory at a particular position. However, the 
type of intent data that may improve the performance of the conflict detection function in the ATMA is 
related to operations on or near the airport surface. 

Ownship states can be computed accurately because the data to indicate “intent” to takeoff, “intent” 
to land, etc., is available from the ship’s flight computers. Some examples of these data sources might 
include: 

• Takeoff intent - on the runway, lined up with runway heading and Engine Pressure Ratio (EPR) 
button or Autothrottle button pushed, throttle position. 

• Intent to land - Autoland engaged, lined up with runway and descending, 1LS tuned and aircraft 
following localizer and glideslope, landing configuration and airspeed. 

However, these intent data are not available for traffic. With the increase in capacity envisioned by 
NextGen, traffic will be more densely spaced making the need for knowledge of traffic intent even more 
critical. 

The following traffic intent data/information could potentially enable more effective, timely, and 
error free CD&R in the ATMA. More analysis is necessary to determine the potential benefits of utilizing 
this data/information. 

• Takeoff mode - Determining when traffic is actually taking off can currently be determined by 
monitoring ground speed. Knowing that the pilot has taken the runway and has engaged the EPR 
mode or Auto throttle mode, for example, would indicate takeoff intent as well as knowing throttle 
position (advanced full forward) in lesser equipped aircraft. 

• Go Around mode - Knowing when traffic is aborting a landing can currently be determined by 
noting that the aircraft is climbing and accelerating. A more timely means would be to transmit 
when the go around is initiated (go around button pressed or throttles advanced and aircraft 
configured for climbing). 

• Rejected Takeoff mode - Knowing when an aircraft aborts takeoff can eventually be determined by 
observing the traffic’s greatly reduced speed and either stopping on or exiting the runway. The 
ability to know if the power goes to idle (throttle position), brakes are pressed and/or thrust 
reversers are used could result in a more effective means of determining if a rejected takeoff 
occurred. 

• Land and Hold Short Operations (LAHSO) - Knowing intent to follow LAHSO operations at 
airports like ORD might prevent false runway incursion alerts in an intersecting runway situation. 
The logic would be similar to the rejected takeoff criteria above for determining intent to stop. 
Knowledge of intent to LAHSO could be obtained via pilot entry or, in the absence of such an 
entry, via broadcast of ATC instructions (see below). 

• Termination of taxi - Knowing that the traffic that could become a conflict is aware and braking 
might allow the CD&R algorithms to delay alerting to prevent nuisance alerts in cases where the 
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errant traffic’s nose barely passed the hold short line or the errant traffic could stop before 
becoming dangerously close to another aircraft on the surface. 

• Air-ground - When an aircraft is determined to be on the ground, ADS-B transmissions will 
contain surface message content instead of airborne message content. The ADS-B surface message 
lacks altitude data which is necessary for low altitude CD&R. It is not clear that the current method 
of switching between airborne and surface ADS-B messages will be sufficient for ATMA CD&R. 
Aircraft with air-ground detection would switch at the proper time. All others would switch based 
on the presence or absence of airspeed, ground speed, and radar altitude which will either cause an 
early or delayed switch between Airborne Position Messages and Surface Position Messages. 
Knowing precisely when traffic is on the ground based on weight on wheels or nose wheel squat 
could potentially resolve this ambiguity. 

• Air Traffic Control Instructions - Knowledge of other traffic’s clearances (e.g., “cleared for 
takeoff’, cleared to land”, “land and hold short”) for operations in the ATMA could potentially 
increase safety and prevent conflicts and collisions through awareness of the intentions of other 
traffic. Awareness of traffic’s intended taxi path and hold short clearances may also reduce 
conflicts at taxiway and runway intersections. Taxi awareness and conflict prevention/detection 
can be further refined in the NextGen environment with knowledge of traffic’s 4-D taxi path and 
required times of arrival at intersections. 

D.3 ADS-B Altitude Data 

An area of concern for CD&R in the ATMA is the granularity of all ADS-B reported altitudes. The 
source for ADS-B altitude is currently either Global Navigation Satellite System (GNSS) or barometric 
altitude reported to the nearest 100 feet or 25 feet [RTCA 2003]. These accuracies are sufficient for 
aircraft that are airborne and not near the surface (above 1000 feet AGL), however, they may not be 
accurate enough for ATMA CD&R. 

Sources of error for barometric altitude reporting include instrument calibration, rounding altitude to 
the nearest 25 or 100 feet, and incorrect barometric pressure setting. An incorrect setting of 0.5 inches 
Mercury could cause the altitude report to be 500 feet higher or lower than the actual barometric altitude. 
GNSS position data also has the greatest error in its vertical measurements, i.e., the height above the 
ellipsoid. As a result, aircraft could be mistaken for being on the ground while airborne or vice versa, 
which could cause CD&R algorithms, such as ATCAM, to incorrectly determine the traffic operational 
states. (See Section 5.4.4). 

ADS-B altitude accuracy could be improved if radio altitude were used in lieu of GNSS or barometric 
altitude when the aircraft is within 1000 feet of the airport surface. Many radar altitudes provide radio 
altitude accuracy to within 2 feet. Barometric and GNSS altitudes are encoded to the nearest 25 feet or 
100 feet within the airborne position message format to conserve the number of bits utilized in data 
transmission while still providing suitable altitude accuracy at the higher altitudes. This rounding of 
altitude values coupled with the errors inherent in GNSS height above the ellipsoid or barometric altitude 
may prove to be unacceptable for CD&R in the ATMA. Since the range of values for the radio altitude 
are capped, usually to 2500 feet, the space allocated within the ADS-B airborne message format can 
represent the radio altitude to the nearest foot. Using radio altitude in lieu of GNSS or barometric altitude 
to represent a much more accurate value for altitude AGL, would enable ATMA CD&R algorithms to 
make more accurate aircraft state decisions. 

Another area of concern is the transition between ADS-B airborne and surface messages (see 
previous section). Radio altitude is used as the criteria to switch between airborne and surface messages. 
Aircraft with a radio altitude of 50 feet or less are considered to be on the ground when ground speed is 
100 knots or less [RTCA 2006], Since ADS-B surface position messages do not include altitude, the 
transition to surface messages at 50 feet AGL or greater due to the errors mentioned above would cause 
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the loss of altitude reports before touchdown, which could cause nuisance CD&R alerts. Using alternate 
criteria, such as weight on wheels or nose wheel squat for those aircraft that provide that information, 
would ensure the switch to surface position message transmission would occur when the aircraft is on the 
ground. 

Further research is needed to determine the effect of ADS-B altitude accuracy and surface message 
reporting on ATMA CD&R. 
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